home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Fritz: All Fritz
/
All Fritz.zip
/
All Fritz
/
FILES
/
BUSINESS
/
MAKEDEMO.LZH
/
MDEM4B.EXE
/
MANUAL.TXT
< prev
next >
Wrap
Text File
|
1992-10-28
|
71KB
|
1,624 lines
M A K E D E M O
-----------------
Version 4
-----------
U S E R ' S M A N U A L
---------------------------
Last updated: October, 1992
_______________________________________________________________
| |
| MakeDemo is NOT a public domain program. It is Copyright (c) |
| 1989 - 1992 by WindhamWoods Publishing. All rights reserved. |
|_______________________________________________________________|
COPYRIGHT INFORMATION
This software and accompanying documentation are
protected by United States Copyright law and also by
International Treaty provisions. Any use of this software in
violation of Copyright law or the terms of LICENCE.DOC will be
prosecuted to the best of our ability. The conditions under
which you may copy this software and documentation is clearly
outlined in LICENCE.DOC.
Registered users may install MakeDemo on a computer
attached to a network, or remove it from one computer and install
it on another, provided that the copy will not be used by more
users than the number for which it was licensed.
As a registered user, you may distribute any file which
you create in part or in whole with this software. Further, you
may include any screen(s) that you received with the MakeDemo
distribution as part of your own presentation(s).
Licensee shall not use, copy, rent, lease, sell, modify,
decompile, disassemble, otherwise reverse engineer, or transfer
the licensed program except as provided in this agreement. Any
such unauthorized use shall result in immediate and automatic
termination of this license.
Where differences exist between the foregoing information
and that contained in "LICENCE.DOC," the latter shall govern.
ASP Information
_______
____|__ | (R)
--| | |-------------------
| ____|__ | Association of
| | |_| Shareware
|__| o | Professionals
-----| | |---------------------
|___|___| MEMBER
"This program is produced by a member of the Association of
Shareware Professionals (ASP). ASP wants to make sure that the
shareware principle works for you. If you are unable to resolve a
shareware-related problem with an ASP member by contacting the
member directly, ASP may be able to help. The ASP Ombudsman can
help you resolve a dispute or problem with an ASP member, but
does not provide technical support for members' products. Please
write to the ASP Ombudsman at 545 Grover Road, Muskegon, MI 49442
or send a CompuServe message via CompuServe Mail to ASP Ombudsman
70007,3536."
Table of Contents
a. Copyright Information
I. Introduction
II. The Files of MakeDemo
III. Installation
IV. Starting Up MakeDemo
V. What MSHOW looks for in your Creation
Menus
Predefined System Menu Selections
Code Those Screens
Menu Mechanics
Types of Screens
Prompt Screen
Be Mouse Ready
VI. Creating a Presentation with MDEMO
MDEMO Features
Using a Mouse
Large Fonts
Overlays, the Key to Presentation Effects
Screen Test
Viewing a Work-In-Process
VII. Making Single .EXE File Presentations
Branding (Optional)
VIII. MLITE, The MakeDemo Stripped Down Runtime
IX. MDEMO Quick Reference
X. Customer Support
_______________
I. Introduction
MDEMO, for creating, and its companion MSHOW, for
viewing a presentation, together comprise the MakeDemo system
that gives you the ability to present information on a PC or
compatible computer of almost any persuasion, color or
monochrome. And then there is MLITE, a stripped down version of
MSHOW with some limitations on features but worth the trade-off
where disk space is a premium. See section VIII for the
differences.
MakeDemo's architecture promotes
o presenting information in as many as 2000 screens that
include your own menus and sub-menus, as you define them and
may also include DOS level commands and executibles and/or
shellintg out to DOS.
o small files: a typical 100 screen self-contained presentation
consumes 120 kBytes: great for downloading over BBSs.
o small memory usage: less than 80 kBytes of RAM, less memory
intensive than many TSR applications.
o your own user interface design: you design all screens
including prompt screens, context sensitive help, etc.
o language independence: your client sees only what you create.
There are no hard coded screens or messages that pop up in
your presentations.
First, there's MSHOW.EXE. By itself it does nothing:
rather it reads an external or appended 'resource file'. Think
of MSHOW as a library of functions that can interpret your
'presentation' that you create with MDEMO.
Second, there's MDEMO.EXE, used to create presentations
to be displayed by MSHOW.EXE, either separately or combined with
a presentation to form a single EXE file.
MakeDemo gives the novice through expert user the ability
to create slide show type presentations with sound effects,
various screen overlaying techniques, and various delays with
interactive menuing and mouse support. MakeDemo includes tools
to put full presentation into a single .EXE file complete with
"F1 - Help" and your own order form: no extra file listing each
screen for a presentation or a script language to learn if you
want to include menus.
MakeDemo is to screens what a good word processor is to
paragraphs. Think of MakeDemo as a text organizer for files of
screens, not paragraphs. As you work on a creation, add screens,
insert blank screens, import text in 25 line chunks from ASCII
files, screens captured from other software, or other MakeDemo
files, in part or in whole. Then edit one screen at a time, move
segments around or copy segments to "place" on other screens.
Make copies of screens. Delete screens. Save groups of screens to
new files. Sounds like a word processor: except that you scroll
through a file screen by screen rather than line by line. All
with mouse support. But MakeDemo is more. Give your users control
in how to view presentations. Simulate menu driven software for
very realistic demos. Create a hypertext sort of system for
quickly moving through a large presentation, such as a catalog or
book on disk. Use MakeDemo to create your own menuing system for
DOS which additionally includes detail screens about a DOS
program that is available for calling. Or use the extra screens
to provide a little training about the program in question.
Manually override color/monochrome display
formatting. Now, when a "color display" is not strictly a color
display, switch over instantly without first exiting to DOS,
typing in some modifying commands, and then restarting the
presentation all over again. In fact, view a presentation in
process being created in color, as it would appear on a
monochrome display.
Choose from many large fonts when creating outstanding
screens. Create boxes with automatic correction for crossing
lines. Customize your own or add to selection of boxes and fonts
with almost any ASCII text editor.
PLEASE NOTE -
Only one version of MakeDemo exists for both shareware and
registered use. Without the correct validation code, MDEMO
comes up in the 'shareware' mode. You need to register your
use of MakeDemo in order to receive your assigned validation
code in order to bypass the 'shareware' mode.
Both MDEMO and MSHOW have identical and integral WindhamWoods
Publishing 'shareware' screens that appear when certain conditions
are detected. Similarly, MLITE produces a single line
"reminder."
Shareware Users:
The 'shareware' screens appear if -
1. You run MDEMO from the command line and do not include the
correct validation code.
2. You start MSHOW or MLITE to view a presentation either
with no file specified at all, or
with a presentation file specified on the command line
(or integrated into a single .EXE file) created, or last
edited, with an unregistered version of MDEMO.
In all cases, whenever the 'shareware' screen appears, pressing any
key erases that screen and lets you continue, unheeded.
Registered Users:
The serial number for your copy of MakeDemo is located on the
2nd line of the file MDEMO.WWP. Upon start-up, MDEMO reads
that number and imbeds it and the validation code that was
included on the command line with MDEMO into any presentation
file that is edited or created. As a registered user, make
sure that the serial number is yours. The validation code
will only work with it to circumvent any WindhamWoods 'shareware'
screens from appearing.
_________________________
II. The Files of MakeDemo
MakeDemo is supplied in three self-extracting files
listed below. Not only does packing MakeDemo into three files
take about half the disk space, installing MakeDemo on your
system is also easier. Packed into each is the same PACKING.LST
file that completely lists all of the individual MakeDemo files.
The following is a brief description of the three files.
While each can stand alone in its own right, all three contain
files necessary to successfully produce a MakeDemo presentation.
For detailed information on installing MakeDemo on your system,
please read section III - Installation.
MDEM4A.ZIP Overview of MakeDemo
.EXE
Contains the necessary files to produce a single
.EXE executable file, DEMO.EXE from WATCH_ME.1ST
created with MakeDemo. The resulting file with about
55 screens is a fully functioning sales pitch for
MakeDemo.
MDEM3B.ZIP A More Elaborate Presentation
.EXE
This time you can create a single file presentation
of MakeDemo's "help" facility. With about 200
screens, this presentation also created with
MakeDemo is a more elaborate example of MakeDemo's
capabilities. And this archive also contains the
MakeDemo manual.
MDEM4B.ZIP MakeDemo Files
.EXE
Contains MDEMO.EXE and the ancillary utilities such
as the screen capture utility for those who are
ready to start creating their own presentations.
Also included are the various .DOC files that
complete the MakeDemo package. And for those who
would like a bare-bones MakeDemo runtime, there's
MLITE.EXE, great for a "shareware" front end to your
own programs.
_________________
III. Installation
MakeDemo was designed to be accessed from its own
directory. Therefore, you should place all the files supplied
with MakeDemo in its own directory and include that directory in
the PATH statement of your AUTOEXEC.BAT file.
IMPORTANT NOTE:
Be sure to reboot your computer after modifying your
AUTOEXEC.BAT file. If you need help in this area, consult
someone knowledgeable in the workings of DOS.
MakeDemo as supplied in three self-extracting files is
ready for "unpacking" and placing on your hard disk (preferable)
or other floppy disk. The full complement of files takes about
500 kBytes of disk space plus 250 k Bytes for the example files
you'll be creating as you get started.
As part of the unpacking process, you can declare a
destination directory that doesn't as yet exist, in which case
it will first be created automatically and the files unpacked to
it. Where the directory already exists and the files of an older
version of MakeDemo reside in it, you will be prompted before
overwriting an existing file of the same name, to which you
should answer "yes."
HARD DISK INSTALLATION
Simply place the disk in the A drive and type
MDEM4A C:\MDEMO and press <Enter>.
in like manner type
MDEM4B C:\MDEMO and <Enter>.
in like manner type
MDEM4C C:\MDEMO and <Enter>.
Once you have included the MakeDemo files in its own
directory and have included that directory in the "PATH,"
you can then call up MakeDemo from within any other directory.
There's no need to keep multiple copies of a file and then
inadvertently loose track of the current one.
FLOPPY DISK INSTALLATION
Use of MakeDemo on a computer without a hard disk is not
recommended. The following information is provided for those
hearty souls who persist in overcoming self imposed limitations.
You need to format four disks before continuing. Simply
place the master disk in the A drive, one of the
formatted disks in drive B, and type
MDEM4A B: and press <Enter>.
When completed, label disk "MSHOW."
in like manner type, place another formatted disk in
drive
B and type
MDEM4B B: and <Enter>.
When completed, label disk "HELP."
in like manner type, place another formatted disk in
drive
B and type
MDEM4B C: and <Enter>.
When completed, label disk "DOCS."
The fourth disk holds the files for creating and viewing
a presentation.
Place the fourth disk in drive A and the "DOCS" disk
in drive B and type
COPY B:MDEMO.EXE A:
COPY B:*.WWP A:
Replace the disk in drive B with the "HELP" disk and
type
COPY B:MDEMO.HLP A:
Replace the disk in drive B with the "MSHOW" disk and
type
COPY B:MSHOW.EXE A:
When completed, label disk "MDEMO."
________________________
IV. Starting up MakeDemo
Let's start by making an executable of the MakeDemo
"help" system, just as you might do yourself. All the DOS
machine instructions are contained in the DEMO.BAT file, all
ready to run. The MDEMO.HLP file and MSHOW.EXE are combined to
form M_HELP.EXE. The first time you run this program, you'll
see the 1st screen of the "Help" file, a menu screen, AND you
will see disk activity while your computer crunches away creating
an index of all the screens in the "Help" file. The time it takes
to complete this chore depends upon the type machine you are
using. You can use the presentation while the indexing continues
in the background, but response will be sluggish. It's best to
wait until the process is completed before trying to maneuver
through the file. Once the index is created, subsequent viewing
will start almost immediately: the index, stored to disk is not
recreated, but is automatically read from disk into memory, a
much faster operation.
As a registered user, you received a validation code. If
you wish to use MakeDemo and bypass the "Shareware" screens, you
must include your validation code on the command line when
calling up MakeDemo.
NOTE: If you have installed MakeDemo on your hard disk in its
own directory, and have included its directory in the "PATH"
statement of your AUTOEXEC.BAT file and then rebooted, you're
all set to change directory to any other and call up MakeDemo.
If, on the other hand, you are using a dual floppy system, place
your MDEMO disk, the fourth one you created in the unpacking
process, in drive A and a preformatted disk in drive B. At the
DOS prompt type PATH=A:\. Then log onto drive B and you're
ready to call up MakeDemo.
For example, if your validation code is SK1234, you would type
MDEMO SK1234 and <Enter>.
Remember, that code is uniquely yours. Giving it to
someone else along with the program really isn't much of a gift.
After all, the "shareware" screens aren't really that obnoxious.
But violating the copyright laws deprives the authors of MakeDemo
from receiving fair value for value rendered.
If you have any questions once you have called up
MakeDemo you can press F1 to see the "Help" categories from which
to select more detailed help. There's a lot of information in
this help file. It is in itself a MakeDemo creation, similar to
something which you yourself might wish to create. To quickly
get up to speed as to what makes a great presentation, use MDEMO
itself to "Edit" the help file. There's no need to make any
changes to the file. Just go through the screens and see how the
menus are defined and what "appearance" options have been
selected. Dissect it, take it apart. That's right -- go into
MakeDemo and edit them and see some of the behind-the-scenes
stuff. MDEMO is just the editor, if you will; MSHOW, the
presenter. We can talk a lot about interactive menus, but a
picture is worth a thousand words, so to speak.
To "Edit" the help file, select for the working
directory that which contains the MakeDemo files, normally the
MDEMO directory. At the DOS prompt type MDEMO and the validation
code, if you are a registered user, and press <Enter>. When the
menu appears across the bottom of the screen, select "Files,"
highlight the help file, "MDEMO.HLP," and press <Enter>. Up will
pop the first screen of the file. Now to see more of the
screens, use the down and up arrows to move through the file,
observing how the menus are constructed. For now, just observe.
The details follow a little later in this document. Select
"More" to get the other half of the main menu and select
"Appearance" to see what methods were selected for the screen
that is shown. Press <Esc> to move through the three appearance
menus so as not to disturb the choices already selected. When
you're finished, press <Escape> and follow the directions.
_________________________________________________________________
V. What Gives MSHOW a Clue as to What, Where, and How to Present
You need not be a 'programmer' in the old sense of the
word in order to create a masterpiece. Knowing one's way around a
word processor is qualification enough. To create an MSHOW
'presentation' requires following a few simple rules, which we
will get to shortly.
MSHOW interprets your presentation or resource file.
There are just a few rules that impact how you go about its
design. Your presentation or resource file is nothing more than a
series of screens that describe to MSHOW your application. All
the unique information is placed on the screens themselves. Upon
presentation, this 'coding' information is blanked out.
Upon startup, MSHOW almost immediately puts up the first
screen, but then continues to 'index' the remaining screens in
the background until completed. Indexing performs a number of
functions. MSHOW creates a list, by name, of all screens in
memory. MSHOW lets you include 'menus' in your document that uses
this index of screen names. A menu is a list of choices, or
screens, from which your user can select to view next. Hence,
only screens that must be referenced need a unique name. MSHOW
saves this index to disk in a file of the same name, but with
the ".INX" extension. When preparing to display a presentation
MSHOW first looks to see if the index file exists on disk. If
it is found and its date/time stamp is more recent than that of
the presentation file itself, MSHOW reads it into memory. Once
created, this feature is a real time saver, especially on slower
systems.
The index file is in reality an ASCII text file. It can
be printed out using the DOS TYPE command. The name and length
of each screen is stored sequentially, each separated by commas.
You might want to refer to this file created by your own
presentation in order to eliminate conflicts in screen names.
You may also "code" your creation to become a
self-running presentation of sorts. If you wish to let your users
view your document as a presentation (ie. automatically present
screens in menu order at pre-programmed intervals) and
automatically recycle indefinitely, or until <Esc> is pressed,
give your viewer access to the presentation options. (see the
system menu options)
Menus:
There is an optional system menu screen and then there
are the menus that are part of information you are presenting.
The system menu, or virtual menu, has the rudimentary selections
such as <F1>, <Esc>, <PgUp>, <PgDn>, and <Tab> always active,
regardless of whether or not you assign additional keys to them
or not. More about that later. These selections are always active
whether or not they can be seen on the screen. This menu, if you
have defined your own, is always as close as the <Tab> key or by
moving the mouse to one of the screen edges.
There are reserved names for these screens which MSHOW
looks for upon startup. MSHOW looks for one and only one screen
with one of these names
LSIDE0 TSIDE0 BSIDE0 RSIDE0
PLEASE NOTE: These names are reserved and are not to be used for
any other purpose. If you do by chance try to include them in
your own menu, strange things will happen and the results will be
something less than acceptable.
The architecture of MSHOW allows, even encourages, you to
design this system menu screen to your own taste. Of course, feel
free to use whatever screens you like of those supplied with
MakeDemo. If you like, modify them with your own context
sensitive "Help".
Predefined System Menu Choices:
There are a number of predefined functions which your
system menu may or may not include. That's up to you. For
example, to give your viewer the ability to shell out to DOS, you
must include the appropriate selection on the system menu screen.
Certain names are 'reserved' and if used, MSHOW expects
conformance to the appropriate schema. We'll get into this schema
later, but in the interests of being concise, all the information
you will need for referral purposes is included here in one
place.
Those menu selections are
Hard- Soft-
Coded Coded Actions Performed
Keys Functions
-----------------------------------------------------------------
<Esc> QUIT returns the user to the previous menu, or out to
DOS, whichever comes first. In the AUTO
presentation mode, discussed below, the first
press of <Esc> puts MSHOW into the SOUND mode,
discussed below.
<PgDn> PAGEDN causes the next screen to appear provided screen
has no name. A name of "+" or "-" is permitted
where a repeating presentation is desired.
<PgUp> PAGEUP causes the previous screen to appear provided
the present screen has no name. A name of "+" or
"-" is permitted where a repeating presentation
is desired.
<Tab> TAB causes MSHOW to search all screens stopping
at the first with the name "_SIDE0". The "_"
represents the characters "R", "T", "B", or "L".
When using a mouse, MSHOW can differentiate
between the various options, but without the
mouse, MSHOW has no clue as to what the first
letter might be. Only one system menu screens is
permitted.
<F1> HLLP You can provide a sequence of screens as a
general "Help" facility. These might be of a
more general nature, explaining the typical
maneuvers to progress through a presentation.
When a system menu screen is being presented,
either by pressing the <Tab> key or moving the
mouse to an edge, MSHOW presents the first
overlay it finds on the screen. (Hopefully it is
the system menu.) All other screen segments on
that screen only appear when F1 is pressed. (See
section on screen overlays.
POFRM Use this name to define a sequence of screens,
such as a Purchase Order Form, that can be
accessed from the system menu and or associated
"hot" key. Of course, you can name your order
form something different and give access to it
from your own menu.
PRIN This key word tells MSHOW to retrace to beginning
of a menu selection or order form and send all
the pertinent screens to the printer. You have
the option of including a "prompt" screen,
discussed further on, to give the user the
opportunity of aborting the process before
actually starting the print operation. If the
"prompt" screen does not exist in your file,
MSHOW sends the form to the printer, by default.
A screen is a chunk of 25 lines each. If you want
to print a form on a single sheet of paper of 60
lines, you are not limited to 2 screens. To
prevent particular lines from going to the
printer, merely place an <Alt>13 symbol at the
beginning of that line on the screen. MSHOW
ignores it and skips to the next line.
SHELL Give your users the ability to interrupt viewing
a presentation so as to temporarily go to DOS for
doing something else, and then return to the
application without losing a step.
COLOR MSHOW detects whether the system is configured
with a monochrome or color monitor. In those
cases where the user might not be happy with the
default, include this ability to switch.
FFUNC reserved, but not used.
RSVD reserved, but not used.
R e s e r v e d f o r P r o m p t S c r e e n O n l y
-------------------------------------------------------------
YES
NO
P r e s e n t a t i o n O p t i o n s
---------------------------------------
N_EFFECT No sound or graphics effects
EFFECT Graphics Effects such as overlay sliding, etc.
SOUND Same as above, but includes preset sound effects
AUTO Self running presentation with programmed delays
As part of your presentation, you have the ability to
include your own menus that allow the user to move through a file
in response to your defined menu selections. One group of screens
might explain certain features of your system, another might be
your order form. You can design menus with up to 30 selections on
a single screen, sub-menus up to fifty deep, with a total of 2000
screens in one file. Think of it as sort of a hypertext
application.
Code Those Screens:
There is very little specific coding information that
MSHOW needs to access. MSHOW is designed to do quite a lot on
very little information. MSHOW does need to be able to discover
the names you give to the first screen of a screen sequence.
All these pieces of information are imbedded in lines
starting with either , or ( ie. <Alt> 4 or <Alt> 6
respectively.) These characters are keyboard accessible by
simultaneously pressing the <Alt> key and the appropriate number
key on the numeric keypad.
Lines prefixed with either of these symbols can up to 80
characters long and must appear within the top 6 lines of a
screen. If one line is insufficient, use additional lines,
provided each starts with the appropriate symbol followed by a
comma. The name following either of the first two symbols can
only appear once, if at all, on a screen.
Generally speaking, the characters following these
symbols mean -
( <Alt+4> ) screen name and menu selections ( if any. )
( <Alt+6> ) designates the place on the screen where, just to
the right, the menu selection.
The area of the screen can have multiple lines but can not
exceed 256 character spaces. (For example, 8 rows by 32
columns.) MSHOW uses the color attribute of the area to
delineates it from that of the surrounding area.
Let's take a closer look at the attribute. This is an important
point. MSHOW defines the width of a field by looking for a
background color change as it moves from left to right after
finding the beginning of the selection or field. The foreground
color (the printed characters) can differ along the line but
not the background color. When MSHOW detects a change, it
calculates the width. MSHOW then travels down the screen in
this last column looking for any change in foreground and
background colors. When found, MSHOW calculates the height of
the menu selection. This is important. You can place menu
selections on adjacent rows using the same background /
foreground colors. You ask "How can that be?" By using a
different foreground color for the last character (usually
hiden as a space where the different foreground color doesn't
show.) Because of this trick, you can implement vertical menus
to your heart's desire.
There is some call for having a vertical menu with the same
background color as the menu itself. How can I define the end
of a menu selection if there is to be no apparant change in
background color? Time to reflect a little. A space or blank
character presents the background color. A character
<Alt>+2,1,9 presents a space or blank character in foreground
color, in effect swapping the background for the foreground
color. By now you probably see the possibilities. At the right
edge of the menu where you want the scroll bar to end, place a
column of character 219 with a same foreground color as the
surrounding background color. The background color can be
anything: it won't show anyway. Now the bars work as intended.
There is one shortcoming though: when viewed in a monochrome
display, that column of characters 219 might show as a black
line.
In general, unless I am trying to give a presentation the look
and feel of some other program, I prefer to delineate menus
from the rest of the screen with lines and/or color changes.
But then -- in a MakeDemo presentation, menus need not be whole
screens unto themselves. Instead, I can draw the viewer's
attention to the idea of the screen and veil a menu as a window
to other areas in the presentation for further invesatigation.
Menu Mechanics:
Here is a typical menu designation. It names the screen
"MENU" and contains six menu selection. Note each line is
prefixed with <Alt+4>. Some printers are unable to print this
character directly.
MENU,ITEM1,ITEM2,ITEM3,ITEM4
,ITEM5,ITEM6
MENU - is the name of the screen. It is only necessary to give
the screen a name if it is to be called from another menu.
ITEM1 - is the first menu selection.
ITEM2 - is the second menu selection. ...and so on.
A screen should never be given a name unless it its to be
assessed from another menu. Here's the rational. MSHOW allows the
user to <PageDown> to adjacent screens if and only if that screen
has no name or if that name is prefixed with a "+" or "-".
If you wish to let your users view your document as a
presentation (ie. automatically present screens in menu order)
and automatically recycle indefinitely, or until <Esc> is
pressed, name the last screen, "-", and the screen to return to
name "+". For example, if you want a repeating presentation to
restart with screen 4, name screen 4 "+". And of course, name the
last screen of the last menu selection "-".
And now you can include DOS Commands in your Menus:
MakeDemo now gives you the ability to create a DOS menu
shell of sorts, by defining menu selections to perform
commands at the DOS level without first exiting your
presentation. For example, you might wish to include the DOS
DIR command as a menu selection, or let your user execute
another program, then return to your presentation. Just
prefix the name of the DOS command with a '&', as in "&DIR=D"
if you want to use a "D" for a "hot" key. That's all there is
to it. Run BAT files or EXE or COM executibles right from
within your presentation. There's a lot you can design into
your presentation.
When <PagingUp> MSHOW lets you go no further back than a
screen with a name. It shouldn't be too hard to visualize that a
sequence of screens can be made inaccessible simply by giving the
first of the sequence a name and then NOT including that name in
any of your menus.
The screen name, in this case "MENU", indicates that this
screen, in addition to having a menu of its own, is to be
accessed only from another menu screen.
MSHOW recognizes hot keys and/or function keys that you
so designate as part of your menu. To use this feature you
include the designator with the menu selection above. For
example, if we change menu item 1 to
"ITEM1=B-FF6",
then pressing the 'B' key or the 'F6' function key will also
cause item 1 to be selected. A more realistic selection might be
"SHELL=S-FF6".
If you layout the menu screen with the "S" for "SHELL" bright
white and the rest of the letters the subdued while or grey,
right away the user intuitively knows that pressing the "S" key
will cause "SHELL" to activate.
All the keys of the alphabet are permitted as well as all the
Function Keys, Control / Function keys, Shift / Function Keys,
and Alternate / Function keys. The following is a list of the
possibilities.
FF1 through FF10
CF1 through CF10
SF1 through SF10
AF1 through AF10
You can designate a hot key with a different foreground
color for that key in your actual menu selection.
IMPORTANT NOTE:
The equal "=" sign must precede the "hot" key, the "-" must
precede the function key designation. Failure to respect this
constraint will appear as non working or unwanted key
assignments.
For example, the following example should clarify things.
Here is a menu selection of 4 rows of 20 characters each. The 'x'
designates different foreground / background colors from those of
the surrounding area.
<Alt+6> xxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxx
You can place selections anywhere on the screen, put them
in list boxes or in bars like those of MakeDemo. Or you can imbed
them in text to make certain words "hot."
Think of menus as a tree with branches. Start at the base
of the tree (DOS) and climb up into the tree and trace your steps
as you explore out to a leaf. You probably won't give your
viewers as many choices as they explore your "tree," but the
concept is similar. With MakeDemo the branches can vary in
length, which is to say that you can show a number of screens
before coming to the next named screen for another menu selection
defined elsewhere. MSHOW lets your viewer progress through a
series of screens until the next screen has a name defined.
Normally MakeDemo restricts the viewer from traversing backwards
through the presentation only until he or she comes to a screen
with a label on it. You remember: a "label" is used by the menu
to know which screen to present when a menu selection is made.
Trying to progress further returns the viewer to menu from whence
he or she came. Except...
There might be times when you might allow the viewer to
move into the next menu selected series of screens without first
returning to a menu. For example, if you are putting together a
catalog with a "Table of Contents," you might just as well let
the viewer roam around in the general area without forcing a
return to the "menu," before moving on. Those screens must have
names starting with a '+'.
For example, suppose screens are arranged as follows:
Screen Label Choices
1
2 <ALT+4>+MENU,GOTO1,GOTO2 <ALT+6>GOTO1
<ALT+6>GOTO2
3 <ALT+4>HLLP
4
5
6 <ALT+4>GOTO1
7
8
9 <ALT+4>GOTO2
10
11
12
13
14 <ALT+4>-MENU
This would be a organization of a typical presentation
file. Here there would be a menu somewhere on screen 2 with two
choices: "GOTO1" and "GOTO2." Screens 6, 7 and 8 associated with
GOTO1 and screens 9 through 14 are reached by selecting GOTO2.
There is only one way to get to screen 6: that is by selecting
GOTO1 from screen 2. However, there is an additional way to
access screen 9; that is from screen 8, but only f the screen
name were prefixed by a "-" sign.
Now, if all that is true, then how does one access
screens 3 through 5? That's simple; just press F1. Those screens
are the "Help" facility, if you choose to have one. To include
"Help," the first screen must be labeled "<ALT+4>HLLP".
The "Help" screens should always be placed just after a
menu screen or after the last screen of a choice. In that way
there is no way for the user to stumble into Help except by
pressing F1.
Now, you may inquire about the choice on screen 14.
There are several things you can do on the last screen. We chose
to use the name of screen 2, the reason being that trying to
move beyond that screen either in manual or automode will cause
the presentation to repeat the presentation starting with screen
2. Or I could have given it no name, in which case, the
presentation would wait there indefinitely for someone to press
<Esc>, which would precipitate a return to DOS.
There is one other nuance having to do with menus that
you might have missed in viewing the presentation. For the
sequence of screens shown above, you might have wondered what
would happen when MakeDemo presented a menu while in the "auto"
mode. Well, MSHOW would assume that you want to sequentially
go through the menu and present every branch out to each leaf,
return to the menu and follow the next branch, and so on. There
might be a situation where you would like your viewer to be in
automatic mode, but then stop at a menu screen and wait
indefinitely for a key press. To do that merely precede the name
of the menu screen with a question mark, "?". MakeDemo leaves it
up to you as to how you wish your viewers to use your
presentation.
Types of Screens:
As you might have surmised from viewing one of the
presentations supplied with this package, MSHOW interprets each
screen before presenting it. A screen is presented either in
whole (completely replacing the previous screen) or various
rectangular shaped portions of the next screen "overlay" their
respective segment of what's already on the screen. For the most
part, you the creator of the presentation determine how a screen
is designed and how it is to be presented. For example, the first
half dozen or so choices from which to choose on the "Appearance"
menu (when working on a screen from within MDEMO) are whole
screen "overlays" if you will. The rest are called "segments."
Strictly speaking, menu screens are show in segments, regardless
of the "appearance" mode selected. We will get to that a little
further on.
How does MSHOW know a "segment" from a whole screen, you
ask? A blank screen (black background with characters, if any,
of a dull foreground color appears transparent when presented by
one of the "segment" modes. To get the attention of MSHOW for
presentation, that portion of the screen with bright foreground
on a black background or any foreground on any background other
than black will appear. MSHOW finds those segments by searching
each row top to bottom looking for the first color combination
described above. Defining that point as the upper left corner of
the segment, MSHOW then travels that row looking for the first
instance of a change in background color, defining it as the
segment's upper right corner. MSHOW then moves back to the
upper left corner and scans down this first column looking for a
change in foreground or background color to determine the height
to then calculate the bottom right and bottom left segment
corners. After presenting a segment, MSHOW then repeats the
process finding and presenting all the other screen segments,
left to right, top to bottom in that order.
IMPORTANT NOTE:
The procedure MSHOW follows to define segment corners differs
from that of defining the corners of menu selections. For
segments the top and left edges solely define the designated
area; for menu selections, the top and right edges solely
define their respectful areas. Don't confuse the two. Here's
the rational. Segments such as "windows" type boxes with
highlighted edges to simulate sloping edges frequently use
the same colors for the top and left edges. Menus, on the
other hand, need the blank space at the end rather than at
the beginning of a line to hide the key to its width.
How does MSHOW present a "whole" screen (i.e. one that
was intended for showing in segments) that is given one of the
"segment" appearance modes? That depends. If the edges of the
screen have the same background and foreground color, no problem.
A quick way to determine that (when in MDEMO) is to select "Pick
& Place" and then "Screen Test." Diamond symbols appear at each
character location, making a visual check very easy. What happens
if the edges are not of the same foreground/background colors?
MSHOW starts with the upper left edge of the screen and scans to
the right looking for a change in background color, and so on.
The results are usually not what you intended. "Screen test" all
screens and correct any problems before viewing a series of
screens with MSHOW. After you have worked on a screen for a
while, the amount of various foreground colors on a blank
sections of screen will surprise you. And what's more, that
carelessness will increase the size of your presentation file,
conceivably by up to 20 percent.
As I mentioned before, "menu" screens come up after MSHOW
finds what it perceives as the first segment. MSHOW does not look
further for more on menu screens. On the system menu screen more
segments are allowed that can be accessed by the viewer pressing
function key F1 for help. That's the only exception. So you want
to be particularly careful with menu screens; lest some blank
segment gets presented: and nothing seems to appear.
The foregoing discussion also applies the "Prompt"
screens discussed next.
"PROMPT" Screen
There is one situation whereby you might wish to prompt
your user with a question and wait for an answer before
proceeding. For example, before sending something to a printer,
you might give your user instructions and a chance to abort the
process before continuing. The screen name "PROMPT" is reserved
for such an event. The screen is defined with
<Alt+4> PROMPT,,,,
and the screen is layed out with 5 selections, the first three
designated for information display, the last two for possible
answers. For example
<Alt+6> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
<Alt+6> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
<Alt+6> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
<Alt+6> Yes <Alt+6> No
The same rules apply here as for menu selection.
And then somewhere on this screen is the information to
be used when a prompt message is to be displayed.
For example,
9,Order Form is Next,Prepare Printer,Continue ?,YES=Y,NO=N,1
The first character, in this case, the '9' is sacrosanct
as well as the 'YES' and the 'NO'. The rest of the prompt line
can be anything. The three character strings appearing after the
'9' separated by ',' can be anything you like to be displayed
centered on the three lines. The individual strings can be any
length, but total length of the line can not exceed 80 characters
and must start at the left edge of the screen. And last but not
least, the last character, here a "1" is the default if neither
of the selections is selected: a "1" indicates a YES, a "0"
indicates a NO.
Be Mouse Ready:
Certain screen areas are "hot," namely the edges: top,
bottom, left, and right. pushing the mouse to an edge causes
MSHOW to look for a system menu screen named "TSIDE0", "BSIDE0",
"LSIDE0", "RSIDE0", representing top, bottom, left and right
edges respectively. If one of these screens exist, the menu is
presented as discussed previously. Usually such a screen is
constructed of two segments: the menu and its context sensitive
help. To work properly, the menu must be positioned such that
MSHOW finds it first before finding the "help" segment. Remember,
MSHOW searches a screen left to right, top to bottom, to find a
segment to display. With this scheme it is not possible to place
a menu across the bottom of the screen with the "Help" segment
above it. The menu must be found first.
_____________________________________
VI. Create a Presentation with MDEMO
Upon typing MDEMO at the DOS prompt and RETURN, the
screen goes blank and a menu appears across the bottom of the
screen. This is screen # 1 of an as yet to be named file. It
happens to be a blank screen because you have not yet done
anything to improve its looks. However, there are things you can
do. You can "Edit" it by selecting "Edit." You can create a box
and "Place" it anywhere on the screen. When you're finished doing
either of the above, press <Esc> and you will be asked whether
you wish to save the screen, and if so, name the file that will
become the presentation you are working on. From that point on
you can perform a number of other operations upon that screen:
like choosing the "More" menu selection to see the other half of
the menu and then duplicating the screen or inserting a blank
screen, to name two.
Or, upon startup, you could select "Files" and "Fetch" a
file that you previously worked on. Or, if you are already
working on a file, choose "Files" again to suspend operations in
the work-in-process in order to look at another file with the
possible goal of inserting one or more screens from it into the
work-in-process. Or you could look at previously "captured"
screens and insert them where desired. Or you can <PgDn> and
<PgUp> through an ASCII text file and import any sequence of 25
line chunks.
Before we go on; we assume that you have digested the
"Help" file, "MDEMO.HLP". You saw them when you ran "DEMO.BAT."
Or if you have dabbled with creating a presentation or two and
have pressed F1, you got to the same file. It's important that
you spend some time viewing this presentation before going any
further in this manual. There's little sense duplicating some of
the same information here when viewing it as a presentation is so
much more satisfying.
Go on: fetch a presentation, move through the screens
with a mouse or arrow keys and then "Save" it. Now you can save
some of the screens to a new file and then work on them
separately. Or you can save a screen to disk and "Fetch" it later
into another file or the same file but in a different place in
the sequence of screens.
When working on a file, MDEMO handles screens just like a
word processor handles pages, except shuffling screens is a
little easier than shuffling pages. Changing the order of screens
can only be done by swapping adjacent screens. You can walk a
screen to a new location, but if the number of screens to bypass
is great, you might better "Save" the screen and then "Fetch" it
at the desired location. Don't forget to go back and delete the
screen at its original location.
For ease in handling, anticipate the presentation you
wish to create and try to break it down into a number of modules:
something along the lines of how you might define a number of
menu selections. Work on these individually and when you are
finished with the pieces, combine them for the final result.
MDEMO Features:
MDEMO has a number of features that make it easy for you
to create stunning screens with a minimum of effort. Not only
can you edit anywhere on the screen, "Window" gives you the
capability to outline portion of the screen and, in effect,
"capture" that portion for editing. Turn on the "word-wrap"
feature by pressing <Insert>. You can "Recolor" that portion
with the F3 and F4 function keys, you can make a "Copy" of it, or
"Erase" it or "Move" it and "Place" it somewhere else on that
screen or another. And you can resize the window by moving the
lower right corner using the <Ctrl> up arrow, down arrow, PgUp,
and PgDn keys.
Remember to always "Place" a box you have created or a
portion of a screen that you have copied or moved before pressing
<Escape> to return to the main menu. In the event that you press
<Esc> without first "placing," in answer to the question, "Save
Screen?", answer "No." and try again. When you want to "place" a
segment on another screen, as long as the segment has not been
"erased" in memory, it can still be "placed."
Using a Mouse:
MDEMO is mouse aware; ie., if the mouse is NOT positioned
in the upper left corner of the screen. If the mouse is anywhere
else, it is active. Pass it over a menu selection and watch that
selection become highlighted.
Using a mouse really speeds things up. If you don't have
one, seriously think of getting one. Whereas some programs let
you move a mouse anywhere on the screen with no apparent effect
other than seeing the mouse cursor move, MakeDemo immediately
shows you "hot" areas of the screen: you'll see the background
and foreground color change when the mouse passes over it. If you
see what looks like a menu, simply move the mouse to a what looks
like a selection and see if its colors change. If it's a
selection you wish to make, merely click the left mouse button.
Still, for those without a mouse, when a menu appears on
the screen, one of the selections is already highlighted. You
can use the arrow keys to maneuver through the various choices
and pressing <Enter> while highlighting a particular one,
selects that one.
Backing out takes a few more words to explain. Whether
using a mouse or not, pressing <Esc> any time causes one to step
back up through the menu tree and eventually out to DOS with
possibly some questions to answer (MDEMO only) before allowing
further retreat. But the mouse works a little differently
whether you are using MakeDemo or viewing a presentation outside
of MakeDemo. If within MakeDemo, moving the mouse off a
possible selection and clicking the left button does the same
thing as pressing the <Escape> key. If viewing a presentation,
such action is ignored. Instead, you must move the mouse right
to display the "mouse bar" on the right edge and move it to the
"Quit" row and then click the left button.
You might ask, "Should I use the mouse in preference to
the arrow keys?" Our experience indicates that using both can
really speed things up. The trick we use here at WindhamWoods
Publishing in making presentations is to primarily use the
mouse with the right hand to block segments of the screen for
moving and copying etc., and with the left hand, be ready to
press the appropriate first letter of the command or menu
selection for what we want to do with it. Even if you have
chosen to hide the menu bars on the bottom lines of the screen,
the selections still work. It saves steps later after you know
the more commonly used keys.
You might want to temporarily disable the mouse when
you're moving or copying a segment around on the screen.
Remember to move the mouse to the screen's upper left corner.
When using the mouse to move "pick & place" segments around on
the screen, note that the segment tries to adjust itself so that
its lower right corner aligns with the mouse. This is not always
possible, especially when the segment is wide, and then the mouse
appears to have no effect. Just be aware.
Clicking the left button once anchors the box temporarily
and brings up a second menu on the next to bottom line of the
screen. It is not necessary to see this menu to use it. Once you
know what selections are available you can select one directly by
pressing the appropriate capitalized letter for that selection.
Large Fonts:
After selecting "Edit" you can then select "Fonts" by
pressing the function key, F10. You will be presented with a
window displaying a word in one of the many fonts that are
available. Press <Return> to select the displayed font; any other
key will display the same word in another font. Continually
pressing a key other than <Return> will cycle through all the
available fonts.
Using any of the large fonts is somewhat crude. For
simple tasks like making titles, etc., they work fine. However,
don't expect to be able to word wrap.
In using large fonts, it's best to get what you want on
each line and then use "Pick & Place" to move a screen segment
into final position, etc. When you are finished using a large
font, one press of <Escape> first gets you back to normal font;
a second press gets you out of the "Edit" mode.
PLEASE NOTE: The fonts are contained in FONTS.WWP, an ASCII file
that you can add to or modify to your own wishes. The system is
pretty easy to figure out. Just be consistent.
Appearance Modes:
There are three aspects to presenting a screen. First is
the method such as simulated blinds or sprinkling. There are
over 20 choices: some for the entire screen, some for overlays
where only a portion of the screen is updated. A second aspect is
"sound." Some of the methods have a built in sound effect unique
to that method. In general, it's best to forgo the sound effects
except where you desire to emphasize a particularly strong point.
They wear pretty thin after hearing them a few times. And lastly,
there is the duration with 5 choices available.
To define the appearance options, they can be accessed by
selecting "More" at the main menu and then selecting
"Appearance."
Overlays, the Key to Presentation Effects.
A screen of 25 rows by 80 columns has room for 2000
characters. However, a screen character also has color
information. For each character there exists a color attribute
"character" defining the background and foreground color.
Therefore, a screen commandeers 4000 bytes, of character space in
memory or on disk.
There are 8 background (all low intensity) colors and 16
foreground (the same 8 low intensity and 8 new high intensity)
colors.
MakeDemo makes the assumption that no presentation
segment will use a low intensity foreground color on a black
background. It really looks pretty drab.
But that is not strictly true. As long as a segment box
has a top and left edge of a high intensity foreground on any
background, MSHOW will recognize the rectangle so defined as a
segment and deal with it accordingly. Just use spaces for the top
row and left column. The foreground color is only used for
characters.
MakeDemo finds the height and width of a segment, as we
discussed before, by first finding the upper left corner of a
segment, remembering the color attribute of that spot, and
"looking" along the top row from left to right for a change in
the color attribute or the screen edge, whichever comes first. In
like manner, MakeDemo "looks" down the left edge to find the
bottom row.
Consequently, you can place segments, as defined by their
upper and left edges, anywhere on the screen and MSHOW will be
able to find and display them. Stack them or place them side by
side.
MSHOW looks for the upper left corner of segments,
first from left to right, then top to bottom.
Put a "bright" top and left edge on a screen and the
screen becomes one segment. Then use one of the display methods
that are designed for use with segments, such as scrolling and
sliding.
Screen Test:
Screen Test is very powerful for looking at a screen as
MSHOW sees it for presentation, especially if you select one of
the overlay or "segment" modes for displaying that screen. It is
only available from the "Pick & Place" menu. It is a momentary
display of the screen showing 25 rows of 80 diamond in place of each
character, spaces or otherwise. The foreground/background color
of each character is the important thing to look at. Remember,
screen segments for overlays and menu selections rely on being
surrounded by different colors and/or dull colored diamonds on a
black background. Use screen test to check the screen. Almost
always, when a screen doesn't appear as designed, it's because
MSHOW doesn't ghet the right clue as to where a segment's
corners are located or where a menu selection highlight ends.
Because screens are compressed before saving, "Screen
Test" is indespensible in minimizing the size of the screen as
saved in the file. In brief, as the screen is compressed, first
and foremost all the color attributes for each character is put
through a form of run length encoding. Basically, each time the
color attribute changes the length of a screen record increases
by three bytes. After working on a screen using "Pick & Place,"
moving a few things around, erasing something, etc., the
screen might be what you want, but the color attibute for spaces
can be anything but one color, preferably dull green on a black
background. From "Pick & Place" it's an easy step to do a
"Screen Test", move the corners to the area in question and
"Blank" that section or recolor it to your desires, then recheck
again with "Screen Test."
Viewing a Work-in-Process:
MDEMO gives you the ability to shell out to DOS. Once at
DOS again you run any program including MSHOW to view your
work-in-process. MSHOW.EXE is the file that presents your
creation(s). This one file can be used in stand alone fashion to
present any number of your creations, as in
MSHOW MYDEMO or
MSHOW THISDEMO or
MSHOW THATDEMO
for viewing. When finished, remember to type EXIT and <Return>
to get back to your MDEMO session.
Incidently, MSHOW has the capability for shelling out to
DOS should you choose to make it available to your viewers.
Or, as discussed in the next section, you can combine
YOURDEMO with MSHOW.EXE using WWP_MAKE.EXE to create a single
executable file. For uploading and downloading over BBSs this
makes the most sense.
__________________________________________
VII. Making Single .EXE file Presentations
Any MakeDemo file can be made into its own .EXE file. But
there are a few restrictions. First of all, the number of screens
in a file can not exceed 2000. And second, if you want to include
your own "Help," it must be part of the same file. I suppose that
goes without saying.
MSHOW.EXE serves two purposes. It can be used as is to
present an MDEMO created file. And it also is the basis for
making those smaller single .EXE file presentations. The utility
WWP_MAKE.EXE does the work for you, by combining the necessary
elements into one file.
The command line must include two arguments and,
optionally, a third. MYDEMO.EXE, if it already exists, will be
replaced with the new. The file names for the two arguments are
arbitrary; use any names you like. If WWP_MAKE can not find the
file specified by the second argument, it terminates and returns
to DOS.
C:\MDEMO> WWP_MAKE MYDEMO.EXE PRESENT.MD4 1234567,ABCD
---------- |_ _ _ _ _ |------------
| |Presenting| Branding
| | File | Info
| |_ _ _ _ _ | |
| | |
+- - - - - -+ | _ _ _ _| |
| | | | |
| MSHOW.EXE | | | |
| | | | |
+- - - - - -+ | | |
| +- - - - - - - -+ |
| | MYDEMO.EXE | |
|_ _ _ | Single | _ _ _ _ _ _ _|
| File |
+- - - - - - - -+
WWP_MAKE combines MSHOW.EXE, your presentation file, and
its associated index file into one .EXE file: everything in one
file. However, the index file must exist first for WWP_MAKE to
complete its task. Remember, MSHOW automatically creates the
index file if it doesn't exist when viewing a presentation with
MSHOW.EXE. The point is: be sure to run a presentation through
MSHOW before making the .EXE executible.
WWP_MAKE also includes a "work around" for a potential
problem with machines using DOS versions prior to 3.0. Let me
explain. With the advent of 3.0, a single file executable can
determine its own file name, while executing, and open itself a
second time to access the appended presentation. To enable your
presentations to function on machines using prior versions of
DOS, MSHOW looks for the file name hard-coded into the EXE
composite file. If you were to "debug" such a file, you would
discover its name imbedded in the code. A subtle consequence of
this "trick" is that your final creation will only work with DOS
versions prior to 3.0 PROVIDED that you DO NOT CHANGE the name of
the executable file after you have created it. It will not work
if RENamed.
Branding
In addition, you have the option of branding your final
creation so that, should your viewer not use the correct
validation code which you assign, any 'shareware' screens in your
presentation will be activated. Your creation will not be
crippled in any way. Any screen with the name "NAG" will be shown
just like any other. You can put anything on it that you like. In
fact you can include more than one NAG screen placed
strategically in your file, as long as each screen has the name
"NAG".
Note the third argument in the syntax for using
WWP_MAKE.EXE. Here you should replace the number '1234567' with
some other number known only to you. That number seeds a quasi
random number generator. You can use any seven digit number above
1000000, or one million;
followed by a comma, with no spaces;
followed by a four digit serial number greater than 1000
to replace, ABCD, which you can choose to your liking.
To find the corresponding password for a unique serial
number, KEY.EXE has been included.
The syntax for using KEY.EXE is
KEY 1234567
where 1234567 is the same seed number discussed above.
KEY will then ask for the serial number you imbedded in
your executable file and will display its corresponding password.
For example, if (as we did in DEMO.BAT) you use the seed number,
1234567, and assign a serial number of 1000, then using the
utility, KEY.EXE, you would calculate the validation code to be
'2236'.
________________________________________________
VIII. MLITE, The MakeDemo Stripped Down Runtime
Registered users have requested a MakeDemo runtime that
takes up as little disk space as possible while still providing
the minimum in functionality. MLITE.EXE weighs in at a little
over
13 k Bytes. It's sole function is to show a series of screens
(i.e. full screens: no overlays.) There is no provision for Help
at the touch of the F1 key. There is no support for either a
mouse or menus. And branding is not supported as well.
There are two ways to exit MLITE. The first is the <Esc>
key which in addition sets the DOS ERRORLEVEL to a 1. The other
is the <Return> or <Enter> key which leaves the DOS ERRORLEVEL
set at 0.
A presentation can be appended to the end of MLITE, just
like with MSHOW, except its length can not exceed 35 k Bytes.
That's about 45 screens, give or take.
Seven and only seven key strokes are recognized:
PgUp or
Up Arrow Key Presents previous screen
PgDn or
Down Arrow Key Presents next screen
F5 Toggles between monochrome and color
Return
or Enter Presents next screen, if it exists, or
exits with DOS ERRORLEVEL = 0
Esc Exits with DOS ERRORLEVEL = 1
MLITE is useful for making a front end for other software
where a few expository screens would help get the novice users
off to a good start. For example, you might want to take a look
at START.BAT. We've used it as a way to start MDEMO with a few
start-up screens that experienced users can later avoid by
calling MDEMO directly from the command line. To those of us in
the shareware business, especially ASP members, now we can
present a more elaborate shareware message to first time users
without mucking up the programs themselves with allocated, but
never used again, memory. Disk vendors can now incorporate a
small front end on all the disks they distribute.
You'll note that START.BAT uses MLITE.EXE with a command
line argument: namely the name of the file to present,
MESSAGE.1ST. I could have used WWP_MAKE to combine the two into
an .EXE file, but I left them separate to minimize the size of
the archive.
IMPORTANT NOTE:
WWP_MAKE expects to append the presentation file to a copy of
MSHOW.EXE to produce the final .EXE file. Therefore, if you
wish to fool WWP_MAKE into using MLITE.EXE instead, you must
REName it to something like MSHOW1.EXE, COPY MLITE.EXE to
MSHOW.EXE, run WWP_MAKE, and then REName MSHOW1.EXE to
MSHOW.EXE.
To automate this process, you might consider writing two batch
files and place them in the directory with all the MakeDemo
files. Here are the two listings:
REM GO_MLITE.BAT
COPY MSHOW.EXE MSHOW1.EXE
COPY MLITE.EXE MSHOW.EXE
and
REM GO_MSHOW.BAT
COPY MSHOW1.EXE MSHOW.EXE
With the MakeDemo directory listed in your "PATH" statement of
your AUTOEXEC.BAT file, you can make the switch while working in
any other directory.
_________________________
IX. MDEMO Quick Reference
Function Keys
F1 - Help F2 - MakeDemo Logo
F3 - Background Color F4 - Foreground Color
F5 - Color/ Monochrome F6 - Print (normally off)
F7 - (not used) F8 - Grab Color
F9 - Menu (normally on) F10 - Fonts ( Edit only)
Pick & Place / Box / Recolor
Move Box
Horizontal Left or Right Arrow Keys
Vertical Up or Down Arrow Keys
Mouse Mouse controls lower right
corner. Box follows.
Resize Box
Horz. <Ctrl> + Left or Right Arrow Keys
Vert. <Ctrl> + <PgUp> or <PgDn> Keys
Mouse HOLD DOWN Right Button.
Anchors Upper Left Corner.
Drag Mouse to Change Size.
Release Right Button.
Copy Save segment to memory, leaving screen intact.
Move Same as "Copy" plus erase blocked screen area.
Erase Erase saved screen segment kept in memory.
Blank Erase blocked screen segment.
Place Replace screen segment with that now visible.
___________________
X. Customer Support
WindhamWoods Publishing is a small software company owned
and operated by Warren Munroe. At WindhamWoods Publishing we
believe that the PRIMARY purpose of business is service, not
profit. This concept is fundamental to our approach to product
development, production and marketing. WindhamWoods Publishing
has been producing top quality computer software at reasonable
prices, continuously, since 1989.
Please feel free to contact me (Warren Munroe) at any
time if you have any questions, comments or suggestions. I can
be reached by mail, phone, or Compuserve:
Warren Munroe Phone: 603.893.2667
WindhamWoods Publishing Orders & Tech Support 603.893.2667
P. O. Box 314 CompuServe 72260,1700
Windham, NH 03087
U.S.A.